How we at Professional Wiki typically do dependency injection in MediaWiki extensions:

• We call the place where we get control from the framework (MediaWiki) an "entry point". SparqlLua is such an entry point. External Content has an EntryPoints folder: https://github.com/ProfessionalWiki/ExternalContent/tree/master/src/EntryPoints. Entry points are typically static functions for hook handlers or classes extending some MediaWiki base class.
• We minimize logic in these entry points and typically do not attempt any form of dependency injection, sidestepping the MediaWiki mechanisms for doing so entirely.
• In cases there is substantial logic to be executed, we put this into a dedicated service. Often we call this a UseCase, Action or Query. This class can have many collaborators. For instance, a service to make HTTP requests. Example: https://github.com/ProfessionalWiki/ExternalContent/blob/master/src/UseCases/Embed/EmbedUseCase.php
• We construct said service and the dependency graph (including configuration) it needs in the entry point. Typically this construction logic gets extracted into a top-level-factory for the extension. Example: https://github.com/ProfessionalWiki/ExternalContent/blob/master/src/EmbedExtensionFactory.php

Ultimately what we are after is well-designed code that is easy to test and understand and is reasonably robust against framework changes.

For this PR that means:

• No need to touch HookHandlers or extension.json
• You need a new PHP class with public function runQuery( string $sparql ): array. Since we have full control over this class, you can require all config and collaborators in the constructor. You can also develop and test this class without dealing with MediaWiki stuff.
• You could construct the new PHP class directly in SparqlLua (the "entry point"), and thus do all access to MediaWikiServices::getInstance() there. There should be no global access beyond that point (ie in the new class)
• If you use the FileFetcher mini-interface in your class, you can use the already existing test doubles in your tests. This is what External Content does. You can see how it constructs an instance of FileFetcher at https://github.com/ProfessionalWiki/ExternalContent/blob/master/src/EmbedExtensionFactory.php#L105-L112.

Having looked at my notes in #1 again, I just realized that if we go with the POST request approach, then using FileFetcher won't work, as it only has a URL parameter. Which means we either use HttpRequestFactory directly, or create a new wrapper, if HttpRequestFactory proves too difficult to deal with in tests.

I cannot recall running into this before. @malberts do you know of a place where we solved making POST requests in MediaWiki testable?

I'm not aware of any place where we're doing external requests (POST or otherwise) as part of our own code.

Manual Test Evidence